REMARKS 

The application has been amended to correct the cited informalities and to place 
the application as a whole into a prima facie condition for allowance at this time. Care 
has been taken to avoid the introduction of any new subject matter into the application 
as a result of the foregoing amendments. 

The Examiner has rejected claims 1-31 under 35 U.S.C. §101 as purportedly 
being directed to non-statutory subject matter. The Examiner has further rejected 
claims 1-31 under 35 U.S.C. §1 02(b) as purportedly being anticipated by Levitskv , U.S. 
Patent No. 5,742,932. The Examiner has also objected to claims 6-7, 10, 19-20 and 23 
based on certain purported informalities in the claim language. Applicant respectfully 
traverses each of the above-identified bases for rejection. 

At the outset, Applicant notes that claims 27 and 31 have been cancelled. 
Accordingly, any further examination or discussion of those claims is moot. 

With regard to the Examiner's bases for objection to claims 6-7, 10, 19-20 and 23 
based on purported informalities therein, Applicant has amended each of those claims 
in order to address the respective bases for objection. With regard to claim 6, Applicant 
has revised the reference in the claim to "at least one second entity" to read "a plurality 
of second entities", in order to differentiate the second (Subordinate Proposal) entity 
identified in claim 6 from the second (Proposal) entity identified in claim 1. Similarly, 
Applicant has revised the reference in claim 7 to "another second entity" to read "said 
second entity or to another associated second entity", in order to clarify that the second 
(Sibling Proposal) entities identified in claim 7 may be subordinate to either the second 
(Proposal) entity of claim 1 or to another second entity. Next, Applicant has revised 
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claim 10 to include the further limitation "where there are a plurality of second entities", 
to clarify that the scope of the claim includes other second entities in addition to the 
single second (Proposal) entity of claim 1 . Applicant has also revised claims 19-20 and 
23 in the same manner as claims 6-7 and 10, respectively, in order to address the 
Examiner's identical bases for objection thereto. Accordingly, reconsideration and 
withdrawal of the bases for objection to the claims is respectfully solicited. 

The Examiner has rejected claims 1-31 under 35 U.S.C. §101 on the basis that 
the claimed invention is purportedly directed to non-statutory subject matter. 
Specifically, the Examiner has stated that the invention of claims 1-27 purportedly 
"claims entities that compose a system defined merely by software", and that claims 1- 
27 purportedly "appear abstract and the system in the claims does not seem to handle 
any real world data or provide a practical application." Similarly, with regard to claim 28, 
the Examiner has stated that Applicant purportedly "never recites a computer readable 
medium, and only recites an abstract collection of entities that has no recited real world 
function." Applicant respectfully traverses this basis for rejection. 

Applicant respectfully submits that Applicant's invention of claims 1-26 and 28-30 
does not fall within any category of subject matter which is unpatentable under 35 
U.S.C. §101. The U.S. Supreme Court has identified only three categories of subject 
matter that are unpatentable, namely "laws of nature, natural phenomena, and abstract 
ideas." In re Alappat, 31 USPQ2d 1545, 1556 (Fed. Cir. 1994) (citing Diamond v. 
Diehr, 450 U.S. 175, 185 (1981)). The Supreme Court also held that certain 
mathematical subject matter is not, standing alone, entitled to patent protection. Id. 
However, when a claim containing a mathematical formula, equation, algorithm or the 
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like implements or applies that formula, equation or algorithm in a structure or process 
which, when considered as a whole, is performing a function which the patent laws were 
designed to protect (e.g., transforming or reducing an article to a different state or 
thing), then the claim satisfies the requirements of Section 101. Id. at 1557. A claim 
drawn to subject matter otherwise statutory does not become nonstatutory simply 
because it uses a mathematical formula, equation, algorithm, computer program or 
digital computer. Id. 

Here, there can be no question but that each of Applicant's claims 1-26 and 28- 
30, as amended, are drawn to either a structure or a process which comprises statutory 
subject matter within the scope of Section 101. Indeed, Applicant has amended 
independent apparatus claims 1, 13, 14 and 26 and independent method claim 28 to 
clearly recite the structure associated with Applicant's invention, namely, a computer 
system comprised of a processor and a computer-readable storage medium. Indeed, 
as the Court of Appeals for the Federal Circuit has held, a computer operating pursuant 
to software may represent patentable subject matter, provided that the claimed subject 
matter meets all other requirements of Title 35. Id. at 1558. 

Moreover, the Examiner's position that Applicant's invention "has no recited real 
world function" is simply incorrect. Indeed, Applicant has amended independent 
apparatus claims 1, 13, 14 and 26 and independent method claim 28 to clearly indicate 
the function of the invention as that of "performing negotiation and decision functions 
related to a transaction". However, even notwithstanding Applicant's amendment to the 
claims, the "real world function" of Applicant's invention is readily apparent from the 
specification, which clearly states that the invention relates to "a computer system 
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adapted to perform negotiation and decision making functions related to a transaction" 



(p. 1, lines 10-13) by, inter alia, identifying a client system, identifying an object in that 

client system, defining a transaction, modeling at least one external agent to carry out a 

transformation, defining the types of decision that may be made, and determining the 

responses in relation to those decisions (p. 2, lines 5-19). This clearly comprises a 

function which the patent laws were designed to protect, e.g., one of "transforming or 

reducing an article to a different state or thing". 

Indeed, Applicant's use of a computer system to perform negotiation and 

decision making functions related to a transaction is analogous to the Alappat 

applicant's use of circuitry elements to convert waveform data samples into a display on 

an oscilloscope, which was held to constitute patentable subject matter. As the Court of 

Appeals for the Federal Circuit stated in that case: 

Although many, or arguably even all, of the means elements recited in 
claim 15 represent circuitry elements that perform mathematical 
calculations, which is essentially true of all digital electrical circuits, the 
claimed invention as a whole is directed to a combination of interrelated 
elements which combine to form a machine for converting discrete 
waveform data samples into anti-aliased pixel illumination intensity data to 
be displayed on a display means. This is not a disembodied mathematical 
concept which may be characterized as an "abstract idea," but rather a 
specific machine to produce a useful, concrete, and tangible result. The 
fact that the four claimed means elements function to transform one set of 
data to another through what may be viewed as a series of mathematical 
calculations does not alone justify a holding that the claim as a whole is 
directed to nonstatutory subject matter. 

/of. at 1557-58. Here, Applicant's claimed elements likewise function to transform one 
set of data supplied by a client system to another set of data, as a result of a transaction 
defined by an external agent. Applicant's invention is not an "abstract idea", but rather a 
specific machine and method to produce a useful, concrete and tangible result — a 
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transaction. Accordingly, reconsideration and withdrawal of the rejection of claims 1-31 
under 35 U.S.C. §101 are respectfully solicited. 

The Examiner has also rejected claims 1-31 under 35 U.S.C. §1 02(b), as 
purportedly being anticipated by Levitskv . Applicant respectfully submits that the cited 
Levitskv reference should be deemed incapable of teaching or suggesting the 
patentably distinguishing structure and mode of operation of Applicant's invention, and 
that claims 1-26 and 28-30 should be deemed patentable thereover. 

The Levitskv reference discloses a method of accounting for a transaction cost 
and currency exchange relative to customer accounts in a hybrid mail system. The 
method begins by establishing a data center, a first remote data entry point, and a 
second remote data entry point which has mailpiece production means. A set of 
parameters which define a mailpiece, a unit cost where known for each parameter, a 
destination for the mailpiece, and a choice of debiting or crediting a customer account 
are determined at the first remote data entry point. The parameters and known costs 
are transmitted to the data center and to the second remote data entry point. The 
mailpiece is produced at the second remote data entry point and a unit cost for each of 
the mailpiece production and delivery elements is calculated at the second remote data 
entry point and transmitted to the data center. A total unit cost of the transaction is 
calculated at the data center and then converted to a transaction cost by multiplying the 
total unit cost by a currency conversion factor. The transaction cost is then entered into 
a customer account database, a transaction database, and transmitted to the first 
remote data entry point. 
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Applicant respectfully submits that independent apparatus claims 1, 13, 14 and 
26 and independent method claim 28 patentably distinguish over the Levitsky reference. 
In essence, the method disclosed by Levitsky is a precise example of the sort of prior 
art systems specifically described in Applicant's Background section, at p. 2, lines 14- 
20. That is, Levitsky describes a single purpose system which has to be set up to 
undertake a particular function, namely in this case hybrid mail transmission and 
accounting, and does not assist at all in the design of computer systems generally. 

In contrast, Applicant's invention provides a transactional computer system which 

is separate from the client system which defines the particular application required, but 

nevertheless enables any desired transaction type to be set up or modeled using the 

system. Applicant's invention is not, for example, limited purely to hierarchical mail 

transmission and accounting, or even to transmission and accounting of anything. 

Indeed, the broad scope of Applicant's invention was accurately summarized by the 

European Patent Office Examiner in his comment in the International Preliminary 

Examination Report, which stated that: 

The present invention solves the technical problem of how to realize in a 
computer a uniform and general transaction model which a user can adapt 
to many specific types of transactions. 

Levitsky cannot possibly be deemed to disclose each and every element of 
Applicant's invention. First, Levitsky does not disclose interrelation with a client system, 
as is now required by Applicant's independent claims, nor does it provide a means for 
modeling a counterparty to a transaction, or enabling a decision to be made to accept or 
to decline the transaction. Moreover, Levitsky does not at all disclose a method of 
programming a computer, as set forth in Applicant's claim 28. For example, there are 
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no steps disclosed in Levitskv of setting up first, second or third identities of the type 
and having the characteristics set out in that claim. 

Moreover, Applicant respectfully submits that the Examiner has made a number 
of conclusory assertions regarding the disclosure of Levitskv , which are not at all 
supported by the specification of that reference. First, with regard to claims 5 and 18, 
the Examiner states that Levitskv purportedly "discloses the second entity 86/88/90 
additionally identifies the direction of negotiation between the two parties". However, 
the Examiner has failed to indicate how this occurs, and indeed it is difficult to conceive 
of how Levitskv could possibly disclose such a function, when the system disclosed by 
Levitskv does not even contemplate any negotiation whatsoever between the customer 
and the mailer. To the contrary, Levitskv simply discloses that the customer selects a 
variety of parameters defining a mailpiece, and is charged a set rate by the mailer 
based on that selection of parameters. Additionally, the Examiner's statements that 
Levitskv purportedly discloses (i) "at least one third entity 98/100/102/104 is a partial 
entity indicating a partial response from a second entity 86/88/90" (with regard to claims 
9 and 22), and (ii) "the system does not validate data input from the system" (with 
regard to claims 1 1 and 24) are conclusory, and not at all supported by any citation to 
the specification of the Levitskv reference. 

To put it simply, the Levitskv reference teaches only a particular method of 
accounting for transaction costs and currency exchange in a hybrid mail system. That 
reference does not even remotely teach or suggest a generalized transactional system 
which can be adapted to many specific types of transaction — as is the case with 
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Applicant's invention. Accordingly, reconsideration and withdrawal of the Examiner's 
rejection of claims 1-26 and 28-30, based on Levitsky , are respectfully solicited. 

Inasmuch as dependent claims 2-12, 15-25 and 29-30 merely serve to further 
define the subject matter of their respective independent claims, which themselves 
should be deemed allowable, reconsideration and withdrawal of the rejection of those 
claims based on the references cited by the Examiner, and allowance thereof, are 
likewise respectfully requested. 

Applicant respectfully submits that the application as a whole is now in a prima 
facie condition for allowance at this time. Therefore, reconsideration of the application, 
and allowance of claims 1-26 and 28-30, are respectfully solicited. 

Should anything further be required, a telephone call to the undersigned at (312) 
456-8400 is respectfully requested. 

Respectfully submitted, 

Dated: April 5^2004 

Herbert H. Finn 

One of Attorneys for Applicant 

CERTIFICATE OF MAILING 

I hereby certify that this AMENDMENT AND COMMUNICATION is being 
deposited with the United States Postal Service as First Class Mail under 37 C.F.R. 
§1.8, postage prepaid, in an envelope addressed to: Box IBfciFee Amendment, 
Commissioner for Patents, P.O. Box 1450, Alexandria, VA 22313-1450, on the date set 
forth below. 

Dated: April 2004 

Herbert H. Finn 
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SUBSTITUTE SPECIFICATION - MARKED -UP VERSION 

U.S. Pat. App. No. 09/786,263 

5 TRANSACTIONAL COMPUTER SYSTEM 

BACKGROUND OF THE INVENTION 

This invention relates to a transactional computer system, 
namely a computer system adapted to perform negotiation and decision 
10 making functions related to a transaction. 

Transactional computer systems are known for use in the 
financial and business world for conducting transactions such as, 
for example, ordering product, currency exchange, or the sale and 
purchase of stock, shares and bonds. Such systems are designed 
15 specifically for the particular function or functions which they are 

to perform. 

Rule-based systems using what is generally known as artificial 
intelligence are also known. These are based on a large number of 
rules which are specific to the particular environment in which they 

20 are to be used. A given system is designed for a particular type of 
transaction, and if a new type of transaction is envisaged a new 
system will have to be designed specifically for that purpose. 

We— I have appreciated that it would be highly desirable to 
provide a generalised transactional system which can be adapted to 

25 many specific types of transaction, and furthermore we I have 

appreciated that such a generalised transactional computer system 
can be made by using the ideas and features described in the 
following and claimed in the claims appended to this description. 

30 SUMMARY OF THE INVENTION 

The invention is defined in the independent claims below to 
which reference should now be made. Advantageous features are set 
forth in the appendant claims. 

According to the present invention there is provided a 
35 transactional computer system comprising a plurality of entities 
including at least one entity of each of the following forms, a 
first entity (Thing entity) having the properties of identifying a 
client system and uniquely identifying an object in that client 



system, a second entity (Proposal entity) for defining a 
transaction, the second entity being subordinate directly or 
indirectly to a first entity and having the properties of modelling 
at least one external agent to carry out a transformation in 
5 relation to the first entity, and a third entity (Decision entity) 

capable of communicating with a second entity and having the 
properties of defining the types of decision that may be made, and 
determining the responses in relation to those decisions. 

Preferably the computer system further comprises at least one 

10 fourth entity (Assignment entity) subordinate to an associated first 
entity, the fourth entity having the properties of uniquely 
identifying the associated first entity, and identifying a 
particular type of assignment or transformation to be applied to the 
first entity. This entity may be combined with the second entity. 

15 Additionally the computer system preferably further comprises 

at least one further entity (Tender entity) associated with a 
plurality of second entities and a single first entity, and 
identifying at least a quantity. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The invention will now be described in more detail by way of 
example, with reference to the drawings, in which: 

Figure 1 illustrates the heirarchical hierarchical structure 
5 of the entities in a preferred computer system embodying the 
invention; 

Figure 2 is a flow chart illustrating the NewEntity procedure 
in the preferred embodiment of the invention; 

Figure 3 is a flow chart illustrating the RegisterEntity 
10 procedure in the preferred embodiment of the inventions- 
Figure 4 is a flow chart illustrating the LoadHierarchy 
procedure in the preferred embodiment of the invention; 

Figure 5 is a flow chart illustrating the Math: AddDecision 
procedure in the preferred embodiment of the invention; 
15 Figure 6 is a flow chart illustrating the Cube: Apply Decision 

procedure in the preferred embodiment of the inventions- 
Figure 7 is a flow chart illustrating the Item (EntityKey ) 
procedure in the preferred embodiment of the invention; 

Figure 8 is a flow chart illustrating the Math: GetMathValue 
20 procedure in the preferred embodiment of the invention; and 

Figure 9 is a flow chart illustrating the Cube: GetValue 
procedure in the preferred embodiment of the invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 



GENERAL DESCRIPTION 
This system is embodied in a computer software module which, 
5 when included in a client system, will capture the complexity of its 
negotiations, but leave the description of those transactions to the 
client system. The system makes possible the management of the 
transaction space in a straightforward and effective manner. It 
does not, however, manage the transaction space directly. Rather, 

10 it supports the modelling of the transaction space in a convenient 
and effective manner, and then, once modelled, it is for the client 
system to respond to the situations discerned and captured in the 
model. The power of the system is in its flexibility for modelling 
and managing the client system's complex transaction space. 

15 The system will only capture and supply information without 

using it for its own internal manipulation. It is better to record 
what people claim, and then leave the external clients/parties to 
resolve their claims, than it is to try to decide the truth of a 
matter. Consequently, the validity or otherwise of the supplied 

20 information has no bearing on the system. However, it may have a 

significant bearing on the satisfactory use of the system; therefore 
the client system should validate the information supplied and act 
accordingly. 

The system comprises a hierarchy of entities: a Thing, a 
25 Proposal and a Decision, and optionally an Assignment and/or a 

Tender. Each entity type has a set of properties appropriate to its 
role. These are described in more detail below as part of the 
preferred embodiment. It is a feature of the system that an 
extension of the modelling environment can be achieved by the 
30 provision of additional properties per entity. 
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THE THING ENTITY 
The system supports the modelling of the existence of external 
objects by provision of a 1 Thing 1 entity. In the preferred 
embodiment, the Thing entity has fields ClientSystem, and 
5 ClientSystemRef erence . The ClientSystem field is an identifier of 

the client system itself, and the ClientSystemRef erence field is an 
identifier by which the implicit existence of an object identified 
by that Reference is posited. 

No validation as to the nature of that implicit object is 
10 either attempted or warranted, nor of any other information 
pertaining to the world outside the system. 

A ClientSystemRef erence to a Thing must be unique, so that all 
behaviours and data to a common external thing will be mapped and 
managed by a common internal Thing. Client applications must ensure 
15 that they have implemented an appropriate nomenclature to ensure 

unique references per client system. 

THE ASSIGNMENT ENTITY 
The system supports the modelling of assignments or 

20 transformations applied to external objects. It does so by 
provision of an 'Assignment' entity. An Assignment, for the 
purposes of the system, is regarded as a transformation that may be 
applied to a Thing, for example an operation which can be conducted 
in relation to an object. Thus, in the system's entity hierarchy, 

25 an Assignment is subordinate to and applies to a Thing. 

An Assignment will comprise in particular an identifier for 
the particular type of assignment or transformation to be applied. 
This key information is supplied by the external client system in 
the Assignment's 'Redirection 1 field, see below. 

30 Timing of an assignment will often be significant to the 

external client. A facility to recognise timing may, if desired, be 
provided by the inclusion of fields appropriate to each of the 
distinct entity types. In particular, fields relating to overall 
deadlines for Assignments may be included in that entity. 



5 



LINKING ASSIGNMENTS 
The system supports sequential modelling of assignments. As 
an example: with a Thing(CAR), Assignment (WASH) might be followed by 
Assignment ( DRY) . The assignment sequence is maintained by referring 
5 to WASH as the predecessor to DRY. 

THE TENDER ENTITY 
The client system is allowed to group together a set of 
proposals, thus allowing more complex negotiation behaviours to be 
10 modelled. For example, as its name implies, Tenders and auctions 
may be modelled. The system allows the creation of the Tender 
entity and notes its corresponding external reference. 

THE PROPOSAL ENTITY 

15 The system includes an important facility to model the 

existence of agents to carry out the transformations. As an example 
this might be a cleaning machine which is required to wash a car. 
This is supplied by a 1 Proposal* entity. 

A client system wishing to identify the potential for an agent 

20 to impact an assignment's fulfilment will create a Proposal. Since 

in the preferred embodiment the Proposal has a bearing on a 
particular Assignment, it is subordinate to an Assignment in the 
hierarchy and in the preferred embodiment applies to a single 
Assignment only. Where there is no Assignment entity, a Proposal 

25 may be subordinate to a Thing; either way it is seen that a Proposal 
is subordinate directly or indirectly to a Thing. 

The identification of an agent by a client system is at no 
time validated by the system, but is deemed to be supplied by the 
client system as a rational and satisfactory identity. 

30 The system provides for modelling situations where the 

potential action of the agent may often have arisen as a matter of 
negotiation. The counter-party to the agent in this negotiation is 
also identifiable by the client system. 

The system includes a facility to distinguish the current 

35 direction of the negotiation. 

The Proposal itself carries a rich set of features, sufficient 
and appropriate to the complexity of the environments it is intended 
to be capable of modelling. 
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The preferred embodiment supports the following features 
within a Proposal, each being a field supporting input by the client 
system. The identity of the agent capable of impacting the 
Assignment is held in the field 'Downline 1 . The counterparty to the 
5 agent in this negotiation is held in the field 'Upline'. In regard 

to a specific proposal, the Upline will have no direct impact upon 
the Assignment. The direction of the negotiation is implemented as 
a boolean flag ' DirectionGoingUp ' , which may be either true or 
false . 

10 For example, a proposal going DOWN, whereby the party making 

the proposal is the Upline and expects a reply from the Downline, 
models a request or command. Conversely, a proposal going UP, 
whereby the party making the proposal is the Downline and expects a 
reply from the Upline, models the function of volunteering. 

15 A proposal is something to be considered and a decision made 

on it. A proposal is therefore conveniently recorded using the 
expression Consider. Do, as will be seen below. 

As indicated above, a facility to recognise timing may be 
provided by the provision of fields to reflect the same. Deadlines 

20 for making a decision, and for complying (completing an assignment) 

may be included in the Proposal Entity. 
GROUPING PROPOSALS 
By grouping proposals it is possible to extend the flexibility 
of the modelling environment to support the tracking of complex 

25 interactions. For example, cause and effect, flow modelling, 

command and control and the like, can be grouped. This grouping is 
accomplished by using Subordinate Proposals and Sibling Proposals. 

SUBORDINATE PROPOSALS 

30 A further feature of the preferred system is the modelling of 

subordinate proposals. For example, in a factory, a 
Thing (CLIENTORDER) with an Assignment ( FILL) may require a sequence 
of proposals before it can be fulfilled. This may include the 
interaction of several people. These proposals should be grouped 

35 together. To achieve this the ProposallD of the Superior proposal 

is recorded in all subordinate proposals using the field 
SuperiorProposalRef ID . 
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SIBLING PROPOSALS 
A further feature of the system is the grouping together of 
proposals regarding the same matter. For example, if in a warehouse 
a customer wants 1000 ball bearings, but there is only 800 on the 
5 shelf, then 200 will have to be refused. All of this information 

will be stored in many proposals, but all regarding the same matter 
(i.e. the order for 1000 ball bearings). To achieve this grouping 
all sibling proposal entities store the original ProposallD in the 
field Sibl ing Proposal Ref I D . 

10 

COMBINED PROPOSAL/ASSIGNMENT ENTITY 
As described above, the assignment entity is optional. The 
features of the assignment entity, if included, may be combined with 
15 a proposal entity to provide a combined proposal/assignment entity 

which has the properties of both a proposal entity and an assignment 
entity . 

THE DECISION ENTITY 

20 The system records the response from the counter-party in 

regard to a corresponding proposal. This is the role of the 
Decision Entity which is subordinate to and can communicate with a 
single one of the Proposals. Delegated proposals are tracked by 
passing the Decision for a Subordinate Proposal to the Superior 

25 Proposal. An individual position in a negotiation is tracked by 

passing a Decision for a Sibling Proposal to all the other Sibling 
Proposals with the same SiblingProposalRef ID field. 

The response recorded by the decision entity can be: decline, 
accept, partially accept, or forward. Forwarding involves accepting 

30 the proposal but finding another agent actually to undertake it. 

The responses are recorded in the form Decline. Do, or Accept. Do, and 
so on, as appropriate. 
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THE DECISION SCHEMA 
In order to derive effective meaning from the system, external 
decisions need to be recorded in a consistent, effective and 
intuitive manner. The protocol for so doing is implicitly provided 
5 by the creation of a logical structure, termed the decision schema. 
The decision schema comprises multiple dimensions and defines what 
types of decision may be stored. Each dimension comprises a set of 
direct fields and a set of derived fields: 

Direct fields define the types of decision that may be 
10 stored. 

Derived fields summarise the consequences or impact of 
the decision. 

It is desirable that the direct fields represent a set of 
mutually exclusive states, whereas the derived fields need not be 

15 mutually exclusive. Each field is assigned an index into the 
dimension. A decision type node is then defined as a vector, 
comprising one index from each dimension. Decisions of that type 
have their quantities applied to that node, so that each node 
accumulates a summary of like decisions. 

20 The Decision Schema is a facility which client applications 

may use to model complex negotiations in a manageable and effective 
manner. A client application must, however, be clear as to its 
decision semantics, in order to make use this feature. An example 
of a Decision Schema is given below in the more detailed description 

25 of the preferred embodiment. 

THE DECISION CUBE 
A decision cube is built in the code in the form of a 
multidimensional array. It is used to store the quantities 
30 associated with each decision. Each element of the array should be 
initialised to zero. 

DESIGN PRINCIPLES FOR DECISION SCHEMAS 
Decision states (within a dimension) are exclusive. It is 
35 meaningless to record both an agreement to NotDo something, and yet 
that it is Done. If an agent agrees to NotDo something, and yet 
declares it Done, then it is regarded in the context of the system 
as a rogue agent. 
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The decision cube does not preclude recording inappropriate or 
meaningless information. As noted above, it is a fundamental design 
principle that it is better to record what people claim, and then 
leave the external clients (or parties) to resolve their claims, 
5 than it is to try to decide the truth of a matter. Thus the system 
can record both a NotDo and a Done, and let the client system scan 
for such occurrences, and then implement whatever procedures 
necessary at that point. 

Decision states may be partial. This requires the proposal to 

10 have a Quantity. For example: a proposal to ship 12 crates of water 
(Consider . Do . 12 ) may have the response: Accept. Do. 6, Decline . Do . 4 ; 
leaving 2 undecided (Pending) . 

This also leads to a further observation: that a proposal 
using a Quantity is deemed to refer to a homogeneous assignment. 

15 Thus, with shipping bottles of water, it is assumed that the parties 
to the proposal are indifferent between two bottles of water from 
the same assignment. If partial quantities need to be 
differentiated, then they should be differentiated as different 
Things, and then renegotiated accordingly. Thus a crate of 20 

20 pieces of fruit (12 Apples and 8 Oranges) is perfectly acceptable as 
a Thing, provided the system is not expected to discriminate between 
Apples and Oranges. If it is, then it should be registered as 2 
shipments: one of Apples [Quantity 12], and the second as Oranges 
[Quantity: 8] 

25 

OPTIONAL ENTITIES 
The entities Assignment and Tender are optional members of the 
hierarchy. Specifically a Proposal may be created for a Thing 
without requiring an Assignment or Tender. This facility is 
30 provided to support very simple scenarios, without the overhead of 
the unnecessary creation of Assignment and Tender entities. The 
hierarchy will always include Thing, Proposal and Decision entities. 
This heirarchical hierarchical structure is illustrated in Figure 1. 
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REQUIREMENTS 

The basic requirements needed to support a physical 
implementation of the system are: 

A facility to define the distinct Entities, their 
5 Properties, and the Values associated with these 

Properties . 
A facility to create the Entities 
A facility to have such Entities persist. 

A facility to identify particular instances of Entities. 
10 A facility to set, edit and retrieve the Property Values 

of such Entities. 
A facility to manipulate Entities in a Hierarchy. 



THE PREFERRED EMBODIMENT 
15 The processes required to implement the system will now be 

described in more detail, including in particular the construction 
of the Entity hierarchy, and adding decisions to the hierarchy. 

The specific functions (processes) described in more detail 
below are: 

20 

NewEntityO The facility to create a new member entity of 

the hierarchy 

RegisterEntity ( ) The facility to load an entity (into memory) 
LoadHierarchy ( ) The facility to load directly a full 

25 subordinate tree 

ApplyDecision ( ) The facility to increment the multidimensional 

data array, or cube 
Item() The facility to retrieve a pointer to a member 

entity 

30 Cube: GetValue ( ) The facility to retrieve a cube's value at a 

particular node 
Notif yEvent ( ) Advising Client System of an event 



Of these functions, only two are intended to be accessible to 
35 clients/parties external to the system, namely NewEntityO and 

Item() . The function LoadHierarchy ( ) could be achieved by multiple 
applications of RegisterEntity ( ) but it is convenient to have it 
available as a separate function in its own right. 
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The only further facility required to provide an effective 
minimal embodiment of the system is then: 



This is a trivial process and need not be further discussed. 

The utility of the system will often require a client 
application to be able to determine the state of a particular 
entity, by examining its properties. This function provides that 
facility . 

The following describes the sequencing and sub-processes 
necessary to support each of the key function processes highlighted 
above. The descriptions should be read in conjunction with the 
flowcharts in Figures 2 to 9 with the same title. Numeric 
references refer to these flow-charts individually. 

In the preferred embodiment of the system, the hierarchy 
consists of Things, Assignments, Tenders, Proposals and Decisions. 
Since their processing internal to the system is largely similar, ee 
it is more convenient to regard them all as instances of a 
generalised Entity. An implementation of NewEntity ( ) therefore may 
be read as 

"Construct a facility, of the type: NewEntity (EntityTypeName ) 
where EntityTypeName is one of: Thing, Assignment, Tender, 
Proposal, Decision. " 
This allows further hierarchies to be readily developed, but at the 
cost of more sophisticated code to handle the distinct types. 

Notation: 

Numbers: 1. Numbered boxes in the accompanying 



EntityPropertyValue ( ) : 



Retrieve the Value of a Property of an 
Entity. 



flow-charts . 



Restrictions : 



Exclusions : 



[Not Thing] 



[Thing only] 



Entities only of [this] type 
Entities not of [this] type 



Universal : 



[All] 



Entities of all Types. 
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NewEntity () 

This is the facility to create a new member entity of the 
hierarchy and is illustrated in Figure 2 of the drawings. The 
procedure applies to all the entities Thing, Assignment, Tender, 
5 Proposal, and Decision. Note however that Step 1 applies only to a 
Thing, Step 4 does not apply to Decision, and Step 5 applies only to 
Decision. 

Arguments: The properties of that Entity. See Entity Properties, 

below . 

10 1. [Thing only] A Client Reference to a Thing should be unique. 

A check is made to see if such a Client Reference already 
exists . 

la. If it does, the process is deemed to have failed. 

2. [All] Add a new record to the appropriate EntityType database 
15 table. Include the data from the arguments to the NewEntity () 

call. 

3. Retrieve a unique ID (within that EntityType) for the new 
entity . 

4. Register () the new entity in memory, see below and Figure 3. 
20 (Create a new object in memory, of that type, with the 

appropriate data as supplied by the arguments in the call to 
the function . ) 

5. Proposal: Math: AddDecision ( ) , see below and Figure 5. Since 
something has happened which could have a bearing on the 

25 client systems behaviour (e.g. a new Thing to be considered, 

new Assignment to be processed, new Tender to be negotiated, 
Proposal to be considered, or Decision to be evaluated) , -se— an 
EventNotif ication is sent out to the client system to make it 
aware of the event, in particular its type, and its ID. See 

30 Notif yEvent ( ) 

6. Notif yEvent () . Finally, an ID is returned (non-zero, in this 
embodiment) , unique within the EntityType, so that the caller 
of the process may subsequently refer to this particular new 
entity, in calls to Item(), by its new EntityName. 

35 Regis terEntity ( ) 

This is the facility to load an entity (into memory), and is 
illustrated in Figure 3 of the drawings. The procedure also applies 
to all the entities Thing, Assignment, Tender, Proposal, and 
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Decision. Note however that Steps 2, 3, 4 and 6 do not apply to a 
Thing, Step 3 does not apply to Assignment, Step 7 does not apply to 
Decision, and Step 9 applies only to Thing. 

Arguments: The properties of that Entity. See Entity Properties. 
5 Arguments: In addition, the ID's of the Entity's superiors in the 

Hierarchy. 

1. A check is made, to discover whether this particular entity 
has already been loaded. If so, there is no need to load it 
again. Processing proceeds to Step 11, where a Pointer to the 

10 Entity is returned, so that the calling function may directly 

reference its properties. 

2. [Not Thing] Item(): Get pointer to superior thing, see below 
and Figure 7. As the EntityType 1 Thing f , is the root of the 
Hierarchy structure, all instances of subordinate EntityTypes 

15 (but not a Thing itself, hence the exclusion) will have a 

superior Thing. This step proceeds to get a reference to the 
entity's superior Thing, by a call to I tern (ThingID) . The 
ThingID is passed, along with the ID's of any other superior 
entities, in the call to the function. As a further 

20 consequence of the call, since Item() will load the Thing if 

not already loaded, it will load the full hierarchy particular 
to this Thing, including the entity which is being attempted 
to be registered. Hence this call is recursive if the Thing 
was not already loaded. Thereafter, the Thing being loaded, 

25 there is no further call to load the hierarchy, and hence to 

register the entity which originated the call to Thing. In 
the recursive case, this process again checks to see whether 
or not the subject of the original call has now in the interim 
been loaded. 

30 3. [Not Thing, Not Assignment] This step calls Item() as required 
to get pointers to further superior entities. A Thing has 
none, and as Assignment has only a superior Thing, so both are 
excluded from this step. These pointers will be used in Step 
6, to allow an entity to directly reference its superiors. 

35 This step also provides an opportunity to ensure that the 

superiors specified in the call to this function are all 
available, and appropriate to the entity being registered. 
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4. [Not Thing] See Step 2. Due to the recursive nature of the 
call to Item (ThingID) , this step checks to see whether the 
originally requested entity has now in the interim been loaded 
in memory. 

5 5. [All] In this step, a blank (uninitialised, data unspecified) 
instance of this class of entity is created in memory. 

6. [Not Thing] All objects other than a Thing will have 
superiors. In this step, the pointers gathered in Steps 2 and 
3 are now assigned to appropriate properties in the new memory 

10 instance. In this particular embodiment, only the immediate 

superior in the hierarchy is assigned to the new memory 
entity. Higher superiors may then be accessed by chaining 
entity properties, e.g.: 

(Visual Basic) Proposal . Tender .Assignment 
15 (C++) Proposal ( ) ->Tender ( ) ->Assignment ( ) . 

7. [All] [Not Decision] Create and link a Math Crystal. This 
step assigns the property values, passed as function 
arguments, to the appropriate Ob j ect . Properties . Hereafter, a 
client system or internal routine will be able to directly 

20 determine the state of the object, by accessing these Property 

Values . 

8. Assign the Entity's data. 

9. [Proposal Only] A Proposal has a Property Quantity or more 
exactly Consider Quantity. This is the amount that is being 

25 offered for consideration. Where the field is not used or 

required, it may be deemed to have a value 1. It is therefore 
meaningless to consider the impact of decisions (how much has 
been agreed, etc.) if the original target is not known. This 
step therefore adds a Decision as a "Consider", with Decision 

30 parameters Action and BidWanted derived from the proposal 

properties . 

10. [Thing Only] LoadHierarchy ( ) , see below and Figure 3. As 
described earlier and elsewhere, loading a Thing also loads 
the entire hierarchy subordinate to a Thing. It is achieved 

35 by a call to the LoadHierarchy ( ) function. 

11. [All] Processing complete, the process will return a Pointer 
to the newly created memory object. 
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LoadHierarchy ( ) 

This is the facility to load directly a full subordinate tree, 
and is illustrated in Figure 4. Note that Section I comprising 
Steps 1 to 5 processes the intermediate entity types Assignment, 
5 Tender and Proposal. Section II comprising Steps 6 to 9 processes 
the entity type Decision. 

Arguments: The ID (ThingID) of the Thing whose hierarchy is to be 

loaded . 

The process needs to load all the Assignments, Tenders and Proposals 
10 associated with a Thing. It does this by Registering the Entities. 
The procedure is described therefore as follows. 
Section I . 

1. [Not Thing, Not Decision] The process initiates a sub-process 
for each intermediate EntityType in turn. The hierarchy 

15 subordinate to a Thing is being loaded, so Thing is redundant 

and excluded. Decisions are treated differently, later, and 
so here excluded. 

2. Each EntityType f s stored data (database table, in this 
embodiment) is searched for instances of this EntityType, with 

20 the particular Thing as their superior (ie: having matching 

ThingID) . For each found instance, another sub-process is 
initiated, which comprises Steps 3 and 4. 

3. For each entity instance matching the Thing, the entity's 
particular data is retrieved. 

25 4. The new data is passed as arguments in a RegisterEntity ( ) 
call, to load the found entity into memory. Control then 
passes back to Step 2, to search for the next matching 
instance . 

5. Once each entity type has been fully searched, control passes 
30 back to Step 1. If all intermediate types are complete, it 

passes on to Step 6. 
Section II . 

6. With the intermediate types complete, the processing of 
Decisions is now initiated. A loop is initiated, wherein the 

35 Decisions table is searched for decisions subordinate to the 

required Thing (matching 'ThingID 1 ). For each matching 
decision, a sub-process is initiated, comprising steps 7, 8 
and 9. 
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7. For a matching decision, the data is retrieved from the table. 

8. From the Decision's ProposalRef ID Property, and following a 
call to ltem(), a pointer to the Decision's Superior Proposal 
is retrieved. 

5 9. Proposal: Math: AddDecision ( ) is executed, see below and 
Figure 5. 

10. Once all decisions matching the Thing have been processed, the 
process is complete. 

10 Math: AddDecision 

This function is called in NewEntity and LoadHierarchy above, 
and is illustrated in Figure 5 of the drawings. 
Argument : None . 

1. A determination is made as to whether the decision source is 
15 subordinate. If it is, control passes to Step 2. If it is 

not, control passes to Step 3. 

2. The procedure sets Cube=Derived Cube. 

3. The procedure sets Cube=Normal Cube. 

4. Cube : ApplyDecision ( ) , see below and Figure 6. This determines 
20 the quality and type for the selected cube. 

5. A determination is made as to whether the Decision Source is 
Normal (see Steps 1 to 3) . If it is, control passes to Step 
6. If it is not, control passes to Step 7. 

6. Math: Add Decision to Hierarchically Superior Entity. 

25 7. A determination is made as to whether the Proposal has a 

Sibling Ref. If it does, control passes to Step 8. If it 
does not, control passes to Step 9. 

8. Math: Add Decision (Sibling) to Sibling Proposal. 

9. A determination is made as to whether the Proposal is derived 
30 from another Proposal. If it is, control passes to Step 10. 

If it is not, control passes to Step 11. 

10. Math: Add Decision (Derived) to DerivedFrom Proposal. 

11. Processing complete. 
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Cube : ApplyDecision ( ) 

This is the facility to increment the Decision cube's data 
which is called in Math: AddDecision above, and is illustrated in 
Figure 6. 

5 Arguments: Decision parameters. Decision Quantity. 

1. This process needs to translate the decision parameters into a 
node location. It therefore iterates through each of the 
decision parameters. 

2. Selecting the Decision Dimension Key for each parameter in 
10 turn. 

3. It translates the key into an index into that dimension of the 
cube. (See Decision Cube.) 

4. The set of key indices thus obtained then form a vector into 
the cube, so selecting a particular node in the array. 

15 5. The node at this key is then incremented by the noted 

quantity . 

6. The derived fields in the decision schema are then 
recalculated. 

7. The process is then complete. 

20 

Item() 

This function is called in RegisterEntity above, and is the 
facility to retrieve a pointer to a member entity, and is 
illustrated in Figure 7. 
25 Arguments: Entity Key 

1. From the Entity Key supplied, the collection of similar 

EntityTypes in memory is searched, to discover whether or not 
the Entity is already in memory. If it is, the process moves 
to Step 4, and returns a pointer to the entity. 
30 2. If the entity is not in memory, the process calls the Item() 
function with the Entity's ThingID to get a pointer to the 
superior Thing. 

3. Since a call to Item (ThingID) always loads the full hierarchy, 
subsequent new entities will also be directly loaded into 
35 memory. Step 3 is not a process, but simply acknowledges that 

Thing, and its full hierarchy, including the required Entity, 
will be in memory at this time. 
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4 . 
5. 



The collection of the EntityTypes will now be searched again, 
and the appropriate pointer returned to the calling function. 
The process is complete. 



5 Math : GetMath Value . 

This is illustrated in Figure 8 of the drawings. This 
function can be called by a Client system, in order to find out the 
current status of the computer system. 
Argument : None . 

10 1. A determination is made as to whether the decision source is 
subordinate. If it is, control passes to Step 2. If it is 
not, control passes to Step 3. 

2. The procedure sets Cube=Derived Cube. 

3. The procedure sets Cube=Normal Cube. 

15 4. Cube: GetValue ( ) , see below and Figure 9. The value is 

retrieved from the selected cube. 
5. Processing complete. 

Cube: GetValue () 

20 This is the facility to retrieve the Decision cube's data 

which is called in Math: GetMathValue , and is illustrated in Figure 
9. 

Arguments: Decision parameters. Decision Quantity. 

1. This process needs to translate the decision parameters into a 
25 node location. It therefore iterates through each of the 

decision parameters . 

2. Selecting the Decision Dimension Key for each parameter in 
turn . 

3. It translates the key into an index into that dimension of the 
30 cube. (See Decision Cube) 

4. CubeKey=Vector (DimensionKeys) . The set of key indices thus 
obtained then form a vector into the cube, so selecting a 
particular node in the array. 

5. The value of the node at this cube key is then retrieved. 
35 6. Processing complete. 
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COMPUTER RESOURCES & SPECIFICATION 
While not restricted to these particular resources, the 
preferred embodiment of the system has been implemented on computer 
systems currently available. 
5 The prototype of the system was developed on a 133 MHZ Pentium 

Notebook PC with 32Mb RAM (random access memory), and a 2Gb Hard 
Disk, running Microsoft Windows NT, with Microsoft Access as the 
Database, and with the software developed and prototyped both in 
Microsoft Visual Basic 5, and Microsoft Visual C++. 
10 The system was then ported to a Sun Microsystems UltraS, 

running Solaris 2.51, with a Sybase System 11 SQL Server database 
resource, and written in Unix/Ansi C++. 

Thus, the key requirements of the system are readily met by 
the conjunction of a typical computer system, a typical software 
15 coding language, and a typical database resource. 

SOFTWARE DESIGN 
It is readily understood that software design and 
implementation must take into account the possibility of function 

20 calls failing for numerous causes. Since this is a fundamental 

requirement in software engineering, which must be managed in any 
commercial implementation, the needs and skills appropriate to 
support failure will therefore be familiar to any software engineer 
skilled in the art. As such, they do not feature as an aspect of 

25 the claims of the system, such routines and techniques for 

developing robust code have been considered immaterial to the 
explicit description of the particular embodiment of the system. 

SCOPE OF THE PREFERRED EMBODIMENT 
30 The preferred embodiment implements a fixed and limited 

hierarchy, of specified types yet which is of sufficient power to 
provide a modelling and management facility which will cope with 
typical transactions and negotiations encompassed in the world 
today . 

35 In combination with a facility to provide agents for execution 

of processes, it then encompasses a uniform and general transaction 
facility, suitable for example business, domestic, military and 
governmental use. 
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To the extent that these agents may themselves be computer 
processes, then such an environment offers a computerised 
transaction facility. Where these agents do not need to refer to 
non-computer resources for their information to fulfil their 
5 transactions, then to that extent, the environment so described 
becomes an automated one. 

DATABASE 

For each entity type there is a corresponding database table. 
10 The table is given the name of the entity type. Thus, the existence 
of a 'Thing 1 entity leads to the existence of a 'Thing' table. 

THING TABLE 

The Thing Table contains references to objects external to the 
15 system. Each new Thing record added to the table has a unique 
ThinglD. 



Field Name 


Type 


Notes on Usage 


ThinglD 


Long 


Uniquely identifies 
a Thing 


ClientSystem 


String 


Identifies the 
Client System 


ClientSystemRef erence 


Long 


Identifies the external 
object in the Client System 


CI i en t Re f Description 


String 


Optional - Description 
for client convenience 
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ASSIGNMENT TABLE 

The Assignment Table contains references to processes to be 
applied to Thing entities. Each new Assignment record added to the 
table has a unique Assignment ID . 

5 



Field Name 


Type 


Notes on Usage 


Assignment ID 


Long 


Uniquely identifies an 
Assignment 


ThingRef ID 


Long 


Thing this Assignment is 
for 


Instigator 


String 


Supplied by client to 
identify who created 
entity 


Inst igatorRef 


Long 


Supplied by client as 
external reference to 
Instigator 


PredecessorAss ignmentRef ID 


Long 




Redirection 


String 


Precise nature of 
assignment 


Quantity 


Double 


How much of the 
redirection is requested 


The following fields can optionally be included: 


Deadline 


Date 


Date {including time) by 
which an assignment must 
be complete 


Pref err edBy Date 


Date 


Date (including time) by 
which it would be 
preferred to have the 
assignment complete 
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TENDER TABLE 

The tender table contains the information which groups 
proposals. Each new Tender record added to the table has a unique 
TenderlD. 

5 



Field Name 


Type 


Notes on Usage 


TenderlD 


Long 


Uniquely identifies a Tender 


ThingRef ID 


Long 


Thing this Tender is for 


Assignment Re f ID 


Long 


The superior Assignment in the 
hierarchy 


Instigator 


String 


Supplied by client to identify 
who created entity 


InstigatorRef 


Long 


Supplied by client as external 
reference to Instigator 


Quantity 


Double 


How much this tender relates to 
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PROPOSAL TABLE 

The Proposal contains details of the negotiation with an agent 
to perform the process. Each new Proposal record added to the table 
has a unique ProposallD. 

5 



Field Name 


Type 


Notes on Usage 


ProposallD 


Long 


Uniquely identifies a 
Proposal 


ThingRef ID 


Long 


Thing this Proposal is for 


AssignmentRef ID 


Long 


The superior Assignment in 
the hierarchy 


TenderRef ID 


Long 


The superior Tender in the 
hierarchy 


Instigator 


String 


Supplied by client to 
identify who created entity 


Inst i gat or Re f 


Long 


Supplied by client as 
external reference to 
Instigator 


l^i. k-/ V^- _1_ _l_ _l_ i_ _1_ YyJ \w/ O GL -A- 1. \ ~L- L~s 


Long 




Sib ling Proposal Re f ID 


Long 




Upline 


String 


Who has an interest in the 
process being performed 


Downline 


String 


Who will perform the 
process 


GoingUp 


Boolean 


Who initiated the proposal 


BidWanted 


Boolean 


Does acceptance grant right 
to act 


Action 


String 


The action in regard to 
performing the process 


ConsiderQuantity 


Double 


How much of the action is 
proposed 


The following fields can optionally be included: 


ReplyRe qui redBy Date 


Date 


Date by which the right to 
make a decision 
(particularly 
accept /decline) expires 


CompletionRequiredByDate 


Date 


Date by which the accepted 
quantity must be complete 



DECISION TABLE 



Field Name 


Type 


Notes on Usage 


DecisionID 


Long 


Uniquely identifies a Decision 


ProposalRef ID 


Long 


Uniquely identifies a Proposal 


Instigator 


String 


Supplied by client to identify 
who created entity 


InstigatorRef 


Long 


Supplied by client as external 
reference to Instigator 


ConsiderQuantit 

y 


Double 
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withdrawn 


DeclineOuantitv 


Double 


A response, Amount declined from 
proposal 


AcceptQuantity 


Double 


A response, Amount accepted from 
proposal 


ForwardQuantity 


Double 


A response, Amount forwarded 
from proposal 



INSTIGATOR AND INSTIGATOR REFERENCE 

At the creation of an entity record, the client system can 
5 provide two references. One is the instigator of the entity 

creation, and the other is a meaningful reference to the instigator. 

These fields are available for each entity type, however, they 
are of particular significance to the creation of Thing entities. 
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DECISION SCHEMA 

The preferred embodiment implements a three-dimensional 
decision schema, with dimensions: 
Action, Authority and Resolution. 



Direct: fields : 

Direct fields represent the immediate description of the 
decision. The Index for each dimension in this embodiment is noted 
in brackets. 



Action : 

[0] Do: 

[1] NotDo: 

[2] Done: 

Resolution : 

[0] Consider: 

[1] Annul: 

[2] Decline: 
[3] Accept: 
[4] Forward: 



The potential exists that something be 
done . 

The potential no longer exists for something 
to be done . 

The claim is that something has in fact 
been done. 

It is being put to an agent to (action) 
something . 

The (action) is no longer available for 
consideration . 

The agent declines to pursue the action. 
The agent accepts to pursue the action. 
The agent accepts the responsibility for 
the action but will not perform the 
action . 



Authority: 

[0] FullAuthority : 

[1] BidWanted: 



Upon acceptance, the agent is free to 
pursue the action. 

There is no authority to pursue the 
action . 



Notes to clarify the above: 

Consider - the preferred embodiment embeds this in the proposal. It 
is necessary for the logical process that it be part of the 
decision schema, but it more naturally represents the 
opportunity or quantity to be decided upon. 

Annul - allows the modelling of the withdrawal of an offer, rather 
than the offer being declined by the invitee. 



Forward - allows the modelling of the situation where a salesman 

accepts a client order, but will not be fulfilling it himself. 
It will be fulfilled, for example, by the factory floor. 

BidWanted - allows a tender for a contract to be modelled, or an 
5 offer of tickets, where the final allocation will be at the 

discretion of the offeror, not the bidder . 

In the following, these are written in the order: 

Resolution .Action . Authority . 

10 Derived Fields: 

Given the events (decisions) it is then appropriate to ask 
what the current situation is. The creation of derived fields 
therefore allows logical processing or mathematics to be done on the 
direct fields. The preferred embodiment implements the following 

15 derived fields. Calculations to generate the derived fields are 
noted beside the field description. The Identifiers are taken to 
indicate the values or quantities associated by those identifiers. 

For example: (Do - NotDo - Done = Open) should be read as: 
If quantity required as "Do" = 12, and quantity to "NotDo" = 5 and 

20 quantity claimed as "Done" = 3, then the quantity remaining "Open" 
is 12 - 5 - 3 = 4, ie 12 minus 5 minus 3. 
Dimension Indices are in brackets. 

Action 

25 [3] Open: (Do - NotDo - Done) Everything not cancelled or 

complete 

Resolution 

[5] Available: (Consider - Annul) Everything not withdrawn 

30 [6] Potential: (Available - Declined) Everything not declined 

[7] Pending: (Potential - Accept - Forward) 

Everything not decided 

Authority 
35 No derived fields 

Examples 
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Natural examples of decisions which may be expressed in this 
schema therefore are: 

Accept . Do Accept to do something. 
Decline. Do: Decline to do something. 

5 

Extending slightly: consider the following. 

Accept. NotDo Accept to NotDo something (eg: cancel an 

order) 

Decline .NotDo Declines to NotDo something (eg: too late to 
10 cancel . ) 



Consider further: 
Accept . Done : 
Decline . Done : 



Accepts that something has been done. 
Decline to recognise that something has been 
done . 



In the context of the system, a Do recognises the intent or 
potential to Do something, so that to Accept . Do for example sets up 
an expectation that whatever is being referred to will in due course 
20 be done . 

To recognise a Do is therefore to OPEN a potential. To CLOSE 
a potential, so that it can be dismissed from attention, one of two 
things must happen. Either it will in due course be Done or a 
subsequent agreement will be set up to NotDo that which is being 
25 referred to. 

The set [Do, NotDo, Done] therefore reflects a fundamental and 
natural set of potential intents, actions or claims. Given a 
potential that something can be done, so the process is initiated or 
OPENED as a Do; and it remains OPEN until either there is a matching 
30 NotDo, or it is Done. Whereupon it is in effect CLOSED and requires 
no further attention. 

In the example outline above the decision cube will have 
dimensions [4] [8] [2] and each element of the array will be 
initialised to zero. 

35 

Worked Example 

This will apply 2 decisions to a Cube. The first will reflect 
asking someone to consider doing 12 of something (buying 12 bottles 
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of water, for example) . The second will reflect the agreement of 
the individual to the proposal. The details of the nature of the 
transaction are not stored in ef-nor relevant to neither the cube 
ftor the system itself. Rather, only references to the existence of 
5 the transaction are stored. The system manages and captures the 
complexity of the negotiation, but leaves the description of the 
transaction to the client system. 

Decision 1: Asking someone to consider doing 12 of 

10 something. 

Decision Specification : Narrative /Intuitive description : 

Resolution: CONSIDER Please consider the following proposal 

Action : DO to do 

Quantity: 12 12 (of something) 

15 Authority: FULL with my permission to proceed, if you accept. 

Cube Vector: 

(Do = 0, Consider = 0, Authority = 0): Vector = (0,0,0) 

20 Cube Node: 

The active node is therefore Cube[0] [0] [0] . 

Incrementing the value: the node's value is increased by the 
decision quantity . 
25 Cube[0] [0] [0] = Cube [ 0] [ 0 ] [ 0 ] + 12; 

The node Consider . Do . Full is now 12. 

Recalculation of the derived fields 
30 Only a typical case is shown here, for illustration. 

Available . Do . Full = Consider . Do . Full - Annul . Do . Full = 12 - 0 = 12 

Decision 2: The invitee accepts 8 of the proposal 

Decision Type: Accept . Do . Full 

35 Decision Quantity: 8 

Decision Vector: [Do= 0] [Accept = 3] [FullAuthority = 0] 

Implementation : 
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Cube[0] [3] [0] = Cube[0] [3] [0] + 8; 



Restricting to the Do. Full indices, the Resolution dimension 
therefore now looks as follows: 

5 



Resolution 


Quantity 


Consider 


12 


Annul 


0 


Available 


12 


Declined 


0 


Potential 


12 


Accept 


8 


Forward 


0 


Pending 


4 



For a given Action therefore, 2 key foci exist: 
10 How much has been Accepted; and how much is still Pending. 

The first acknowledges a commitment to something, allowing planning. 
The second, unresolved but potential commitments, require follow-up. 

FURTHER EMBODIMENT 
15 The system itself is not limited to or by the preferred 

embodiment. A more sophisticated embodiment may be implemented 
without impinging upon or materially reshaping the fundamentals of 
the system herein described. Some of the additions to the preferred 
embodiment are now outlined. 

20 

ENTITY PROPERTIES 
The system may include the entity property EntityCreatedAT to 
store its TIME of creation. 

The system may include the entity property EntityVoid to 
25 support a facility to remove an Entity from consideration, in effect 

deleting it without actually removing it from the database. 

The system may include the entity property EntityClosed to 
enable a client to decide not to post any further transactions to 
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that entity. Note that this restriction would not be controlled by 
the system but by the client system, otherwise it violates the 
'Reflect don't Control' principle of the system. Additional 
properties which suggest internal control should be avoided or 
5 renamed. 

An Assignment entity may include further information above and 
beyond the simple identification of the transformation. For 
example, if a further embodiment of the system were to support 
deadline modelling, a deadline for the Assignment might be further 
10 included as a field in the Assignment entity. 
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AUDIT TRAIL 

The system may include an audit trail to record the details of 
all transactions passing through the system. 

MATH IN MEMORY 

The system may include storing the complex calculations in 
memory to speed up the overall performance. 

20 ADDITION FUNCTIONS FOR CLIENT SYSTEMS 

The system may include further facilities to enrich the range 
of the functionality available to the client system. An example is 
a query facility, taking advantage of the fact that the storage of 
the embodiment is a database, so that client applications may 
25 implement queries such as: 

Assignments outstanding: Assignments not Closed, Pending 

non-zero 

Assignments overdue: Assignments not Closed, Created 

before X Date 

30 Agreements in place: Proposals with Downline=Y 



DELETING ENTITIES 
The system may include a facility to delete entity data. In 
the preferred embodiment no such facility exists. It is a design 
35 principle that the system does not 'forget 1 or 'lose' information. 
The preferred embodiment regards data deletion, therefore, as an 
internal housekeeping function for the user. 
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Clearly, on limited capacity machines, an unconstrained policy 
of adding data without any facility for deletion will overwhelm the 
resources at some point. Therefore, a policy on deletion of data 
would be prudent. This will typically depend on the rate of 
accretion of new data, the importance of the data, the resources 
available, and policy on data storage, archiving etc. 
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ABSTRACT 

A transactional computer system comprises a plurality of 
entities including at least one entity of each of the following 
5 forms, a Thing entity having the properties of identifying a client 
system and uniquely identifying an object in that client system, a 
Proposal entity for defining a transaction, the Proposal entity 
being subordinate directly or indirectly to a Thing entity and 
having the properties of modelling at least one external agent to 

10 carry out a transformation in relation to the first entity, and a 

Decision entity capable of communicating with a Proposal entity and 
having the properties of defining the types of decision that may be 
made, and determining the responses in relation to those decisions. 
The system preferably further comprises at least one Assignment 

15 entity subordinate to an associated Thing entity, the Assignment 

entity having the properties of uniquely identifying the associated 
Thing entity, and identifying a particular type of assignment or 
transformation to be applied to the Thing entity. This entity may 
be combined "with the Proposal entity. Additionally the computer _ 

20 system preferably comprises at least one Tender entity associated 

with a plurality of Proposal entities and a single Thing entity, and 
identifying at least a quantity. 
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